Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP06。

用過 AI Coding 一陣子的人大概都遇過幾個經典狀況。

明明只是要修一行判斷式，AI 卻順手把整個函式重構了一遍；明明沒有要求，卻自己加了一堆「以防萬一」的錯誤處理；或是改一個小地方，結果連帶動到了不相干的程式碼風格。

這些不是惡意，而是沒有被要求「保守一點」的自然結果。所以我們把幾條行為準則寫進了共用規則裡，讓 AI 在動手前先想清楚：

1. 先想清楚，別悶著頭做：假設要講出來、不確定要問，有更簡單的做法要主動提出來。
2. 簡單優先：只寫解決問題所需的最少程式碼，不加沒被要求的彈性與抽象。
3. 手術式修改：只動你必須動的地方，不要順手「最佳化」旁邊沒壞的程式碼。
4. 目標導向：把任務轉成可驗證的成功條件，例如「修 bug」要變成「先寫一個能重現問題的測試，再讓它通過」。

這四條加起來其實就一句話：先想清楚範圍，只動必須動的地方，再用成功條件證明做完了。

這些規則不是語氣偏好，而是把「不要猜」、「不要過度重構」、「不要把看似成功當成已驗證」，變成整個團隊共同的工作習慣——不管今天是哪個工程師在用 AI，改出來的 diff 風格與範圍都應該是可預期的。

有意思的是，這些規則本身也是我們自己踩過雷才寫下來的：曾經有一次小小的 bug fix，diff 卻牽動了十幾個不相關的檔案，review 花的時間比原本的修正還久。

從那之後，「手術式修改」就變成了不能妥協的一條線。

規則寫好了，但規則本身也會過時。

下一篇來談：當這些共用規則被更新時，AI 要怎麼知道自己讀到的是不是最新版？